## Introduction

\*This post has been updated based on the [Scrum Guide 2020](https://scrumguides.org/scrum-guide.html)

In my [last post](/blog/scrum-events-1-the-sprint/) I’ve started the Scrum Events series and described the first event in Scrum - **Sprint**. If you haven’t read it yet, I recommend you do it before reading this article. 

Today I would like to continue the series by describing the event which  **initiates** the [Sprint](/blog/scrum-events-1-the-sprint/) - **Sprint Planning**.

Please take into consideration that some parts of the **Sprint Planning** that I described are not explicitly explained in the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) and I used examples of the common practices or my personal opinion.

## Sprint Planning - definition and length

Each [Sprint](/blog/scrum-events-1-the-sprint/) starts from the event called - **Sprint Planning**. During this meeting, Scrum Team: [Developers](/blog/scrum-roles-1-development-team), [Product Owner](/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master) collaboratively creates a plan of the work for the upcoming iteration. 

The meeting is time-boxed (the same as all events in [Scrum](/blog/first-steps-to-learn-scrum)) to a maximum of 8 hours for a monthly [Sprint](/blog/scrum-events-1-the-sprint/). Of course in case of shorter [Sprints](/blog/scrum-events-1-the-sprint/), the time is adjusted.

To help you understand the **Sprint Planning**, I would like to continue my analogy to sport from the previous post. This event is like the moment of the **start in sprinting** (short distance running). If you start running too fast, before the signal to begin, the whole race must be restarted due to false start. On the other hand, if you miss the start, it can jeopardize your whole run and final result.

It is exactly the same in [Scrum](/blog/first-steps-to-learn-scrum). The Scrum Team needs to **work together** to start the [Sprint](/blog/scrum-events-1-the-sprint/). If someone will start before others, **transparency** will be lost and it will have a huge impact on the [Sprint](/blog/scrum-events-1-the-sprint/). Additionally, any delays in start, misunderstandings and not clear requirements can also delay the [Sprint](/blog/scrum-events-1-the-sprint/) and negatively affect the final outcome.

## Why?

The first part of the Sprint Planning should be focused on the explanation of **"Why?"** by the [Product Owner](/blog/scrum-roles-2-product-owner). In the [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) it is explained shortly:

> The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

I would add to this description an explanation of the high level idea for the product:

* How will the upcoming Sprint **impact** the development of the product?
* What were the **changes** from the previous Sprint that impacted the top of the Product Backlog? What needs to be taken into consideration during the Sprint Planning?

From my experience, it is much easier to start working on something if you know the **background** and understand the **purpose** of your actions. Of course details for each part of work should be explained in the work item’s Acceptance Criteria, but it is important for the Scrum Team to understand the whole picture.

It can be helpful if the  [Product Owner](/pl/blog/scrum-roles-2-product-owner)  starts from the **Sprints Roadmap**, and explain the Product Goal. I like the roadmap analogy, because I imagine that as a Scrum Team we are starting the trip together. It is much easier to achieve the first goal if we know roughly about the **next destinations.** FYI - it’s different from the roadmap used in project management. This is just high level vision based on the velocity of the team and it is adjusted whenever changes occur. 

![Sprint-Roadmap](img/roadmap.webp "Roadmap")

The next step of the **Sprint Planning** is setting up the [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) by the Scrum Team. It is the objective that they want to achieve during the upcoming iteration. [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) should be valuable and clear to everyone. It helps the team focus and understand why they are doing their work. 

## What?

After “Why” of the [Sprint](/blog/scrum-events-1-the-sprint/) it is time for a discussion about  **what** will be done during the [Sprint](/blog/scrum-events-1-the-sprint/). 
[Product Owner](/blog/scrum-roles-2-product-owner) &  [Developers](/blog/scrum-roles-1-development-team) collaborate on what  [Product Backlog](/blog/scrum-artifacts-1-product-backlog) items will be included in the current [Sprint](/blog/scrum-events-1-the-sprint/). The list of items selected for the Sprint is called **Sprint Backlog**.

If it is not the first [Sprint](/blog/scrum-events-1-the-sprint/) of this team, there are some inputs to the Sprint Planning session like:

* **Projected capacity** - total number of hours that the team will be available during the [Sprint](/blog/scrum-events-1-the-sprint/).
* **Velocity** - average amount of Product Backlog turned into [Increment](/blog/scrum-artifacts-3-the-increment) during previous [Sprints](/blog/scrum-events-1-the-sprint/).
* **Their Definition of Done** - how they will recognize that the work item is “Done”.

It is up to the [Developers](/blog/scrum-roles-1-development-team) to select how many work items can be done within the [Sprints](/blog/scrum-events-1-the-sprint/). It is one the first moments in  [Scrum](/blog/first-steps-to-learn-scrum) when [Product Owner](/blog/scrum-roles-2-product-owner) needs to trust the team members that they will select the right amount of work based on their expertise and previous experience. Nobody knows better how much work  [Developers](/blog/scrum-roles-1-development-team)  can do during the [Sprint](/blog/scrum-events-1-the-sprint/) than themselves.

## How?

Once the [Developers](/blog/scrum-roles-1-development-team) knows why they need to do the work during the Sprint and they decide what will be done, it is time to decide **how** it will happen.

Let’s check what we can read in the  [Scrum Guide](https://scrumguides.org/scrum-guide.html#sprint-planning) about it:

> For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

It is not mentioned there, because it seems to be obvious, but [Developers](/blog/scrum-roles-1-development-team) need to decide **how** they will be **checking** daily if they are going in the right direction with their work. How do they plan to **track the work, communicate** with each other? They will be meeting on a Daily Scrum, but what more?

There are some technical aspects that I believe need to be discussed:

* How will they track the **progress** of our work? Do they want to use the **Kanban** Board? If yes, will they use columns "To do", "In progress" and "Done" or others that will be more accurate for their work?
* Would they like to use **tools** like Sprint Burndown or Burnup charts to see if they are still on the right track in order to achieve the  [Sprint Goal](/blog/sprint-goal-why-do-we-need-it)?
* How about **bugs**? Do they consider having items called "bugs"? If yes, how do they plan to manage them?
* What about **communication** within the team? Do they plan to communicate only face to face or using emails, Microsoft Teams, Zoom or any other tool?

It is possible that there will be more technical aspects that the Scrum Team should discuss. I think that it is important to talk about them and have a common understanding of communication and the whole collaboration process. It doesn’t need to be a long discussion. It can be just a quick agreement to make sure everyone is on the same page.

![How?](img/how.webp "How")

Once it’s all sorted out, [Developers](/blog/scrum-roles-1-development-team) can decide about the **size** of the items selected to the Sprint. Based on my experience this can also be an element of the regular **Backlog Refinement process.** There are multiple ways of estimation eg. Planning Poker (by using Fibonacci sequence), T-shirt sizes, Dog sizes etc. 

The main purpose of this activity is to have a **discussion about items** & to use the sum of estimates to calculate the **Velocity.** It is a great tool that can be used during the planning of the next Sprint.

When all the work is discussed, understood and planned, [Developers](/blog/scrum-roles-1-development-team) can **start their work.** If they discover that they didn’t select enough items for the Sprint Backlog or they selected too many, it can be re-negotiated with the  [Product Owner](/pl/blog/scrum-roles-2-product-owner).

## Summary

The most important takeaways from this post are: 

* Scrum Team [Developers](/blog/scrum-roles-1-development-team) , [Product Owner](/pl/blog/scrum-roles-2-product-owner) and [Scrum Master](/blog/scrum-roles-3-scrum-master)) should attend the Sprint Planning meeting. 
* Sprint Planning is time-boxed to **8 hours** per monthly Sprint.
* The [Product Owner](/pl/blog/scrum-roles-2-product-owner) should explain **“The Why”** of the Sprint - what is the value. Based on it, the whole Scrum Team crafts the  [Sprint Goal.](/blog/sprint-goal-why-do-we-need-it)
* PO and [Developers](/blog/scrum-roles-1-development-team) discuss **items selected for the Sprint,** but the final decision about it should be done by [Developers](/blog/scrum-roles-1-development-team).
* The inputs to the Sprint Planning can be: **projected capacity, velocity and their Definition of Done**.
* [Sprint Goal](/blog/sprint-goal-why-do-we-need-it) & **Sprint Backlog** should be the outcome of the Sprint Planning.
* It is important for  [Developers](/blog/scrum-roles-1-development-team) to discuss **how they will be working d**uring the Sprint - all technical aspects: tools, boards, communication etc.
* [Developers ](/blog/scrum-roles-1-development-team)can **estimate** during the meeting (or during **Backlog Refinement)** how much effort is required to complete Product Backlog Items selected for the Sprint.

This article describes all aspects of the Sprint Planning meeting. It will help you to understand the purpose of this event, how it looks like & what you need to remember about. 

1 post tagged with #sprint planning